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I FIRST CAME TO THE JET PROPULSION LABORATORY (JPL) 
48 years ago, and was taught that what's most 
important for project success is bringing good people 
on board, getting them to come together as a team, 
making certain that they're all on the same page, and 
setting up the mechanisms to keep them communi- 
cating. That much is true to all successful projects — 
but, naturally, it's not as simple as it sounds. 

What, for example, are the most effective 
"mechanisms” for communication? Today, people 
think about email when they think about day-to-day 
communication and PowerPoint for presentations. 
But many believe, including me, that the advent of 
email and PowerPoint has, in some respects, eroded 
our culture of engineering communication. 


Of course, if you need a quick answer, if you're 
working with remotely located team members — 
then email can be a tremendous communication 
tool. So is PowerPoint for presenting an engineering 
summary or presenting the results of a design 
activity. But what's important to note here is that 
neither email nor PowerPoint is an adequate substi- 
tute for engineering documentation. 

By that, I mean if you have people working in a 
technical area, it doesn't matter what it is, at 
periodic times you need to have them capture the 
engineering that has gone on. You need to do that 
with an engineering memo, or a workbook, or a 
technical report — whatever you want to call it. You 
need to do that to provide an audit trail of decisions 
that that can be reviewed and challenged by peers. 
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Cassini Saturn Probe Undergoes Preflighl Testing 


For the record 

A technical memorandum is what we used to call it. 
We used to have a form for the engineers; they 
would put their summary at the top, list their 
assumptions and the boundary conditions next, and 
then go through the analysis — sometimes even 
including a summary of some of the equations 
involved, plus the pros and eons they had consid- 
ered. All of that preceded their recommendations 
and/or summary of actions taken. 

That became a part of the engineering file. 
Anybody could go back and review that or challenge 
it. You could say, "Okay here is the analysis." You 
could give it to another person or to another group 
and have them validate it or critique it. It also stood 
as a good way of handing off information about work 
that had been done to a newcomer on the project. 

What I've seen over the last ten or fifteen years has 
been a gradual erosion of the discipline of that kind of 
engineering documentation. Again, I think it has a lot 
to do with the introduction of email and PowerPoint— 
which, once again, are tremendous tools for commu- 
nicating but not for engineering documentation. 
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The Mobile Service lower is being rolled away from the Titan 
l\ B/Ccntauv launch vehicle carrying the Cassini spacecraft. 


One way of putting it is that email and 
PowerPoint are more like sound bites. You can't 
critique a PowerPoint presentation the way you can 
an engineering memo. It simply doesn't have the 
structure and the completeness that you would find 
in a report or a memo. In many ways communicating 
has become easier, but it's still necessary to keep 
track of where you're going and the decisions that 
have been made. 

But does it really matter? 

Let me give you an example of a time when commu- 
nication was at the root of a project's demise. 1 was 
on the Failure Review Board for the Mars '98 
failures. The Mars Climate Orbiter failure was 
ostensibly caused by a metrics conversion error that 
led to a navigation failure. We were getting the 
navigation data by tracking the spacecraft to 
calculate the trajectory. The data that we got from 
the spacecraft augmented the data from the 
ground — but there had been some inconsistency 
noticed during the mission well before the failure at 
Mars orbit insertion. 

When we observe an inconsistency during 
operations, our practice is to use an engineering 
reporting system, called an Incident Surprise 
Anomaly (ISA) report, to record the discrepancy. It's 
only one page long, but it's a formal report. Once it's 


submitted, it gets tracked. During the course of a 
mission there may be 100 or even hundreds of IS As. 
Once you write an ISA it becomes a permanent 
record in the system. It gets reviewed. Its ongoing 
status gets reviewed. Its closure gets reviewed. People- 
have to buy off and say, “Yes. this Incident Surprise 
Anomaly, whatever it was, is understood now. We 're- 
taken the following steps to prevent it from 
happening again and we’ve corrected whatever it is." 

In the case of the Orbiter, the person who 
noticed this problem didn't use the ISA form. He 
wrote an email message to the person that he 
thought could solve the problem. That person got the 
email message, and he looked at it and worked on it 
for a while. Then his boss gave him something else to 
do that this individual judged to be of higher priority 
than working on the problem outlined in the email. 

I lere is a case where the guy who noticed the 
problem thought he was doing the right thing. He 
wanted to get the problem taken care of quickly. He 
sent the email out. The email went to where the 
spacecraft was being worked. The guy who received 
the email probably could have solved the problem. 
But he didn't. It got forgotten. 

If that message had been generated as an ISA, it 
could not have been forgotten. It would have become 
a permanent part of the engineering documentation. 
In our failure review report, we described the 
problem something like this, "Communication 
channels among project engineering groups were 
too informal.” 

No one would argue that open communication 
is key to project success. What I'm suggesting is that 
we keep in mind that communication comes in many 
shapes and sizes — it's not a one-size-fits-all concept. 
We need to reinforce the distinction between the 
need for rapid communication and the need for 
engineering documentation, which creates products 
that can be peer reviewed and that leave an audit 
trail for engineering follow-up and close-out. • 
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JOHN CASANI came out of 
retirement in 2003 to return to 
the project management ranks 
at the Jet Propulsion Laboratory 
in Pasadena, California. The 
engineering memos Casani champions in this 
article are far from being the only formal commu- 
nication he sets up on his projects. 

“As a project manager, I hold two regularly 
scheduled meetings each week,” explains 
Casani. “One is with just the core project staff, 
and the other gathers a more extended set of 
people working on the project — including people 
matrixed to the project from each of the major 
technical areas* 

In addition, the full project staff— including out- 
of-town team members from other NASA 
centers, government agencies, industry, and 
academia — are invited to monthly meetings and 
many of them make a point of attending the 
meetings in person. “This is the way that we can 
coordinate and keep track of how the project 
is going,” says Casani. “We keep everyone 
informed about what everyone else is doing.” 

Informal communication is just as important. 
Core team members are co-located in “our own 
comer of the building,” says Casani. "We’re in 
contact every day, almost every hour, in addition 
to the meetings we hold." 

For more about John Casani’s remarkable 
career at JPL, see his story, “A New Spin,” in this 
issue (page 6). 





